test(conformance): plugin hook-info field-shape handlers (10-19..10-23) - #602

Plugin hook infos dropped state that the Python and JS SDKs carry, so a
Java plugin could not see per-operation replay status at the attempt and
change hooks, nor operation state at the invocation hooks.

Attempt and change-item fields:

- UserFunctionStartInfo / UserFunctionEndInfo gain `isReplay`, the
  operation-level indicator for whether THIS operation was observed via
  checkpointed state. This is distinct from the existing
  `isReplayingChildren`, which describes the child operations of a
  context body and does not substitute for it.
- OperationChangeItemInfo was a reduced record; it now carries the full
  operation surface (`status`, `attempt`, `isReplay`, `error`), ordered to
  match OperationEndInfo, so an operation seen through a change delta
  exposes the same fields as through the per-operation hooks.

Invocation-info enrichment:

- InvocationInfo gains `operations` and `updatedOperations`.
- InvocationEndInfo gains `operations` and `executionStartTime`; the
  latter was present on the start info but dropped from the end record,
  forcing plugins to correlate back to the start hook.
- `updatedOperations` derives from the input's UpdatedOperationIds
  intersected with the tracked operations, so it is empty on the first
  invocation and names the externally-completed operations on a replay.
- The end-info snapshot is taken at end time, so unlike the start info it
  also includes operations created during the invocation.

ExecutionManager now snapshots the operation ids delivered in the initial
state and exposes non-mutating accessors for them. The attempt hook needs
the replay indicator at its firing site, but getOperation() delegates to
getOperationAndUpdateReplayState, which flips REPLAY to EXECUTION mode as
a side effect; reading it from a plugin-hook site would mutate execution
state. wasObservedAtInvocationStart is a pure containment check instead,
and gives one consistent definition of `isReplay` across the attempt,
change and invocation hooks.

Both invocation maps are keyed by operation id and valued with
OperationChangeItemInfo, now the richest operation snapshot record the
SDK has, so a single conversion path feeds the change hook and both
invocation hooks. The record name is a wart in this role; renaming it is
left as a follow-up.

These are positional records, so the added components surface every
constructor call site. No defaulting overloads were introduced: a
convenience constructor is exactly how a future internal call site would
silently ship empty maps to plugins, which is the failure mode this
change fixes. Call sites in the OpenTelemetry plugin tests were updated
mechanically.

Payload surfaces stay out of scope: no `result` and no execution
input/result on any info.

Verified with the full module build, unit tests and spotless:check. The
conformance handlers that assert these field shapes, and the live suite
results, are in the stacked follow-up PR.

Refs: #604